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Cloud Data Management Interface (CDMI) Media Types 

Abstract 

This document describes several Internet media types defined for the 

Cloud Data Management Interface (CDMI) by the Storage Networking 

Industry Association (SNIA). The media types are: 

o application/cdmi-object 

o application/cdmi-container 

o application/cdmi-domain 

o application/cdmi-capability 

o application/cdmi-queue 
Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6208. 
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Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The Cloud Data Management Interface (CDMI) [CDMI-1], developed by the 
Storage Networking Industry Association (SNIA), is the functional 
interface that applications will use to create, retrieve, update, and 
delete data elements from the cloud. As part of this interface, the 
client will be able to discover the capabilities of the cloud storage 
offering and use this interface to manage containers and the data 
that is placed in them. In addition, metadata can be set on 
containers and their contained data elements through this interface. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Cloud Data Management Domain and Its Relevance 


A storage cloud is a storage service hosted either on premise or off 
premise, across a network. An important part of the cloud model, in 
general, is the concept of a pool of resources that are drawn from, 
on demand, in small increments (smaller than what one would typically 
purchase by buying equipment). By abstracting data storage behind a 
set of service interfaces and delivering it on demand, a wide range 
of actual offerings and implementations are possible. The only type 
of storage that is excluded from this definition is that which is 
delivered based on fixed capacity increments rather than on demand. 


The CDMI defines a set of functional interfaces (data paths) and 
management interfaces (control paths) to create, retrieve, update, 
and delete data elements from a storage cloud. Another important 
concept in this standard is that of metadata. When managing large 
amounts of data with differing requirements, metadata is a convenient 
mechanism to express those requirements in such a way that underlying 
data services can differentiate their treatment of the data to meet 
those requirements. CDMI also defines an extensible metadata system 
for storage clouds. 


As part of the CDMI interface, the client will be able to discover 
the capabilities of the cloud storage offering and to use this 
interface to manage containers and the data that is placed in them. 
In addition, system metadata can be added to containers and their 
contained data elements through this interface. 
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The hierarchy that CDMI defines is as follows: 
o The basic element of storage is an object. 
o Objects are stored in a container hierarchy. 


o CDMI also defines an object, called a queue, which has special 
properties for in-order, first-in, first-out creation and fetching 
of queue objects, similar to a container of data objects. 


o A cloud offering can also support domains, which allow 
administrative ownership to be associated with stored objects. 
Domains can also be hierarchical, allowing for corporate domains 
with multiple children domains for departments or individuals. 

The domain concept is also used to map Access Control Lists (ACLs) 
to principals as well as to aggregate usage data that is used to 
bill, meter, and monitor cloud usage. (Note: The CDMI "domain" 
defined here is not a DNS domain name as specified in [RFC1076] 
and [RFC1024]). 


o Finally, a capabilities resource and associated URI [RFC3986] 
allows a client to discover the capabilities of the offering and 
its implementation of CDMI. 


3. Processing Guidelines 


This section summarizes the processing of each media type. This 
document provides only the essential information. The CDMI 
specification [CDMI-1], which has more details and appropriate 
examples, is the final authority on the processing aspects. 


3.1. Media Type: application/cdmi-object 


A CDMI object is the basic storage element in a CDMI system and is 
analogous to a file within a filesystem. The object is represented 
in the CDMI interface in JavaScript Object Notation (JSON) format 
[RFC4627]. (See the JSON web site at [JSON-1] for general 
information about JSON). Each data object has a set of well-defined 
fields that includes a single value and optional metadata. The 
implementations are free to store the data in any form they choose, 
but the application/cdmi-object SHOULD be represented in the CDMI 
interface as defined in Section 8 of the CDMI specification [CDMI-1]. 


3.2. Media Type: application/cdmi-container 
A container object is the fundamental grouping of stored data within 


CDMI and is analogous to a directory within a filesystem. Each 
container has zero or more child objects and a set of well-defined 
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fields that includes standardized and custom metadata. A container 
can include other containers similar to sub-directories ina 
filesystem. The implementations are free to represent the container 
in any form they choose, but the application/cdmi-container SHOULD be 
represented in the CDMI interface as defined in Section 9 of the CDMI 
specification [CDMI-1]. 


3.3. Media Type: application/cdmi-domain 


Domain objects represent the concept of administrative ownership of 
stored data within a CDMI storage system. A CDMI offering may 
include a hierarchy of domains that provide access to domain-related 
information within a CDMI context. This domain hierarchy is a series 
of CDMI objects that correspond to parent and child domains, with 
each domain corresponding to logical groupings of objects that are to 
be managed together. Section 10 of the CDMI specification [CDMI-1] 
details the information content, representation, and processing of 
domain objects. 


3.4. Media Type: application/cdmi-capability 


Capability objects form a special class of container objects that 
allows a CDMI client to discover what subset of the CDMI standard is 
implemented by a CDMI provider. For each URI in a CDMI system, the 
set of interactions that the system is capable of performing against 
that URI is described by the presence of named "capabilities". Each 
capability present for a given URI indicates what functionality the 
cloud storage system will allow against that URI. Capabilities are 
always static. Section 12 of the CDMI specification [CDMI-1] details 
the representation and processing of capability objects. 


3.5. Media Type: application/cdmi-queue 


Queues are a special class of container object and are used to 
provide first-in, first-out access when storing and retrieving data. 
A queue writer PUTs objects in the queue, and a queue reader GETs 
objects from the queue, acknowledging the receipt of the last object 
that it received. Queuing provides a simple mechanism for one or 
more writers to send data to a single reader in a reliable way. If 
queues are supported by the cloud storage system, cloud clients 
create the queue objects by using the same mechanism used to create 
data objects. Section 11 of the CDMI specification [CDMI-1] details 
the operations and processing of queue objects. 
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4. 


Transport Considerations 
The CDMI operates over HTTP [RFC2616] and does not make sense outside 
the HTTP realm. We do not expect the CDMI to operate over other 
protocols nor to use a transport protocol, such as TCP [RFC793], 
directly. 

IANA Considerations 

IANA has registered the following media types: 
o application/cdmi-object 
o application/cdmi-container 
o application/cdmi-domain 
o application/cdmi-capability 
o application/cdmi-queue 

Media Type: application/cdmi-object 

Type name: application 

Subtype name: cdmi-object 
Required parameters: none 


Optional parameters: none 


Encoding considerations: Assumes that the representation is always 
UTF-8 as defined in [RFC3629] and 8bit as defined in [RFC4288] 


Security considerations: See Section 6 of RFC 6208 

Interoperability considerations: none 

Published specification: RFC 6208 

Applications that use this media type: Implementations of the Cloud 


Data Management Interface (CDMI) defined by the Storage Networking 
Industry Association (SNIA) 
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Additional information: 
Magic number(s): n/a 
File extension(s): .cdmio 
Macintosh file type code(s): TEXT 


Person and email address to contact for further information: 
Arnold Jones, arnold. jones@snia.org 


Intended usage: COMMON 

Restrictions on usage: none 

Author: SNIA Cloud Storage Initiative, cloudtwg@snia.org 

Change controller: SNIA Cloud Storage Initiative, cloudtwg@snia.org 
5.2. Media Type: application/cdmi-container 

Type name: application 

Subtype name: cdmi-container 

Required parameters: none 

Optional parameters: none 


Encoding considerations: Assumes that the representation is always 
UTF-8 as defined in [RFC3629] and 8bit as defined in [RFC4288] 


Security considerations: See Section 6 of RFC 6208 

Interoperability considerations: none 

Published specification: RFC 6208 

Applications that use this media type: Implementations of the Cloud 


Data Management Interface (CDMI) defined by the Storage Networking 
Industry Association (SNIA) 
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Additional information: 
Magic number(s): n/a 
File extension(s): .cdmic 
Macintosh file type code(s): TEXT 


Person and email address to contact for further information: 
Arnold Jones, arnold. jones@snia.org 


Intended usage: COMMON 

Restrictions on usage: none 

Author: SNIA Cloud Storage Initiative, cloudtwg@snia.org 

Change controller: SNIA Cloud Storage Initiative, cloudtwg@snia.org 
5.3. Media Type: application/cdmi-domain 

Type name: application 

Subtype name: cdmi-domain 

Required parameters: none 

Optional parameters: none 


Encoding considerations: Assumes that the representation is always 
UTF-8 as defined in [RFC3629] and 8bit as defined in [RFC4288] 


Security considerations: See Section 6 of RFC 6208 

Interoperability considerations: none 

Published specification: RFC 6208 

Applications that use this media type: Implementations of the Cloud 


Data Management Interface (CDMI) defined by the Storage Networking 
Industry Association (SNIA) 
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Additional information: 
Magic number(s): n/a 
File extension(s): .cdmid 
Macintosh file type code(s): TEXT 


Person and email address to contact for further information: 
Arnold Jones, arnold. jones@snia.org 


Intended usage: COMMON 

Restrictions on usage: none 

Author: SNIA Cloud Storage Initiative, cloudtwg@snia.org 

Change controller: SNIA Cloud Storage Initiative, cloudtwg@snia.org 
5.4. Media Type: application/cdmi-capability 

Type name: application 

Subtype name: cdmi-capability 

Required parameters: none 

Optional parameters: none 


Encoding considerations: Assumes that the representation is always 
UTF-8 as defined in [RFC3629] and 8bit as defined in [RFC4288] 


Security considerations: See Section 6 of RFC 6208 

Interoperability considerations: none 

Published specification: RFC 6208 

Applications that use this media type: Implementations of the Cloud 


Data Management Interface (CDMI) defined by the Storage Networking 
Industry Association (SNIA) 
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Additional information: 
Magic number(s): n/a 
File extension(s): .cdmia 
Macintosh file type code(s): TEXT 


Person and email address to contact for further information: 
Arnold Jones, arnold. jones@snia.org 


Intended usage: COMMON 

Restrictions on usage: none 

Author: SNIA Cloud Storage Initiative, cloudtwg@snia.org 

Change controller: SNIA Cloud Storage Initiative, cloudtwg@snia.org 
5.5. Media Type: application/cdmi-queue 

Type name: application 

Subtype name: cdmi-queue 

Required parameters: none 

Optional parameters: none 


Encoding considerations: Assumes that the representation is always 
UTF-8 as defined in [RFC3629] and 8bit as defined in [RFC4288] 


Security considerations: See Section 6 of RFC 6208 

Interoperability considerations: none 

Published specification: RFC 6208 

Applications that use this media type: Implementations of the Cloud 


Data Management Interface (CDMI) defined by the Storage Networking 
Industry Association (SNIA) 
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Additional information: 

Magic number(s): n/a 
File extension(s): .cdmiq 
Macintosh file type code(s): TEXT 


Person and email address to contact for further information: 
Arnold Jones, arnold. jones@snia.org 


Intended usage: COMMON 

Restrictions on usage: none 

Author: SNIA Cloud Storage Initiative, cloudtwg@snia.org 

Change controller: SNIA Cloud Storage Initiative, cloudtwg@snia.org 
6. Security Considerations 


This section was developed with RFC 3552 [RFC3552] as a guide. CDMI 
is an application interface and the relevant security considerations 
include confidentiality, integrity, access control, and audit. 
Transport and endpoint security artifacts like Distributed Denial of 
Service (DDoS) are orthogonal, and domains like non-repudiation are 
left to the application that employs this interface. 


6.1. Confidentiality and Integrity 


The confidentiality and integrity of the CDMI exchanges are 
determined by the application that uses the interface. CDMI does not 
contain any specific mechanisms and relies on transport mechanisms 
such as Transport Layer Security (TLS) (see [RFC2818]) for 
confidentiality and integrity of the messages across the network. 


6.2. Access Control 


The access control of the CDMI endpoint URLs are beyond this 
specification. If required, applications should use appropriate URL 
authentication and authorization techniques, such as URI routers for 
different classes of users and restrict access based on URI origin. 


For fine-grained control of the CDMI objects, the CDMI specification 
[CDMI-1] contains the Access Control Lists (ACLs) and Access Control 
Entries (ACEs). These are described fully in Section 16.1 of the 
CDMI specification [CDMI-1]. 
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6.3. Audit 


The CDMI specification [CDMI-1] has defined a set of metadata fields, 
as explained in Section 16.3, to facilitate the incorporation of 
access and other audit markers. The CDMI metadata system is 
extensible, and the implementations can add more metadata as required 
by the security posture of the domain. 


6.4. JSON Security Considerations 


JSON-related security considerations, described in RFC 4627 
[RFC4627], apply. 


6.5. Executable/Active Content 


The CDMI interface does not include any directives for active 
content. 
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